Day 1 確立了專案目標後，今天要來聊聊專案會用到的各種技術框架與整體系統架構。

技術棧 (Technology Stack)

在工具的選擇上，考量到與目前工作技能的要求，希望藉由這個專案，加深對公司現有技術棧的理解與應用。
還沒厲害到能深入分析每個工具的優缺點，剛好利用這次機會多了解這些工具~

以下是本次專案預計採用的技術全家桶：

系統架構與服務拆分

選好蓋房子的工具，接著來看看設計圖。這是我目前規劃的理想系統架構：

從上面的架構圖可以看到整個服務的運作流程：

1. 使用者的請求 (API Requests) 會先抵達 Google Cloud 的 外部 HTTP(S) 負載平衡器。整合 Cloud CDN 的功能，可以將靜態內容（如圖片、前端檔案）在全球的邊緣節點進行快取，提升讀取速度；動態的 API 請求則會被分發到後端的對應服務。

2. 後端微服務架構，部署在 Cloud Run 上，並根據功能拆分為四個主要服務：

   • UI Service：負責提供前端 Angular 的靜態檔案。
   • Auth Service：專門處理使用者註冊、登入、JWT 授權等身份驗證相關的事務。
   • FoodPrint Service：核心的業務邏輯服務，處理所有與美食足跡相關的功能。
   • Collaboration Service：負責處理清單共編等協作功能。

3. 所有的後端服務都位於 VPC (虛擬私人網路) 內部，確保網路安全，並根據需求，與以下兩個核心服務溝通：

   • Cloud SQL：我們的 PostgreSQL 資料庫，用來存放核心資料。
   • Cloud Storage：用來儲存使用者上傳的美食圖片等檔案。

4. 維運觀測性 (Observability) 與安全性 (Security) 相關服務：

   • Cloud Monitoring & Logging：所有服務 (從 Cloud Run 到 Cloud SQL) 都會將其日誌 (Logs) 與指標 (Metrics) 匯出，讓我們能建立儀表板，即時監控系統健康狀況並設定警報。
   • Secret Manager：用於集中管理資料庫密碼、API 金鑰等敏感資訊。應用程式在啟動時會動態讀取，避免將機敏資訊寫死在程式碼或設定檔裡。

5. 自動化部署流程 (CI/CD)：

   • Cloud Build & Artifact Registry：利用 Cloud Build 建立 CI/CD 管線。當程式碼更新後，會自動觸發測試、打包成 Docker 映像檔，並將映像檔儲存在 Artifact Registry。最後，再自動將新版的服務部署到 Cloud Run 上，實現自動化更新。

賽期規劃

俗話說的好

理想很豐滿，現實很骨感。

要在 30 天內完成後端開發、前端開發、容器化與上雲的設置，又要認真探究其中技術與背後原理，實在是太勉強了。這次專案的目標會更著重在「記錄學習過程」，寧可多花一點篇幅在介紹理論後才進行實作，確保自己學得扎實，也不會強制要求自己在 30 天內盡善盡美。

初步目標是先以完成基礎的後端服務為主，但希望在 30 天比賽結束之後，能陸續把文章補齊，將這個專案有始有終地完成。